IBIS Macromodel Task Group Meeting date: 2 June 2015 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI) Xingdong Dai * Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC David Banas Marc Kowalski Ericsson: Anders Ekholm IBM Steve Parker Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Nicholas Tzou Maxim Integrated Products: Hassan Rafat Mentor Graphics: * John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp. James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong (Note: Agilent has changed to Keysight) The meeting was led by Arpad Muranyi. ------------------------------------------------------------------------ Opens: - Curtis Clark to take the minutes. -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Walter to send AMI directionality recommendations from previous meeting to the list. - Done. ------------- New Discussion: - Arpad: Michael M., would you like to discuss the directionality BIRD? - Michael M: Yes. - I would like to request that the document I sent out be available on the work archive site. - AR: Mike LaBonte to post it. - Thank you everyone for all the feedback. - Big changes in this version. - Added the Executable_Tx and Executable_Rx. - Removed the direction parameter. - Reintroduced the one [Algorithmic Model] keyword per [Model] restriction. - Changed the Title to better reflect the final proposal. - Changed the Statement of Issue based on Bob Miller's comments. - This version adds Executable_Tx and Executable_Rx to [Algorithmic Model]. - Requirement: I/O type models must have at least one Executable_Tx and at least one Executable_Rx Sub-Params. - Their fields are identical to the existing Executable Sub-Param. - Revised the tables re: reserved parameters and their directionality. - Examples changed. - Should we allow Executable_Tx for 3-State [Model] types? - It could be clear from context if we just keep the existing Executable. - Bob: I prefer using Executable only. - If you have Executable_Tx, then this 3-State type becomes an exception in that it has no Executable_Rx. - Would simplify the parser's job. - Michael M: No problem, I understand. I'm happy either way. - Walter: Implication here is that if you have an I/O you need a Tx and an Rx? - Michael M: Correct, you need at least one Executable_Tx and Executable_Rx. - Walter: Say I have a DDR4 DQ on a controller. - It might have Tx equalization, and it might not. - It might have Rx equalization, and it might not. - So it could have just Tx or just Rx equalization. - That was the impression I got from some statements you [Michael M.] made about the application of this to DDR4 controller buffers. - Did I understand that correctly? - Michael M: Yes, it is possible to just have one. - Walter: In that case, I think we should allow either one or both. - Michael M: In that case, we are setting up a situation where: - If Executable_Tx exists, but Executable_Rx does not exist then we are only using the analog portion of the buffer in the simulation for Rx simulation. - Walter: For a controller example: - Reads might have equalization if you have a CTLE or DFE. - Writes may not if it did not have an FFE. - Writes would be analyzed the traditional IBIS way. - Michael M: Okay. That's a fairly easy change to make. - Walter: One other comment: - I thought last week we agreed to use Executable underscore Tx [these minutes have used this form - Executable_Tx, Executable_Rx]. - Arpad: Walter is correct. - Michael M: [will change BIRD to add the underscore] - Bob: I hear Walter's point. - But what would be the problem of having Executable_Tx and Executable_Rx if one is a straight-through no equalization? - Walter: If you have an AMI model, the implication is AMI processing. - In the example I gave the Tx may not have an FFE. - So in that direction you don't want to do writes statistically with AMI. - Want traditional modeling in that case. - Radek: Question is does the flow for AMI processing need to be addressed? - Does AMI flow need to be augmented to support such a situation? - Michael M: Yes. - Because the request here is to ensure the language supports it. - Arpad: Isn't that a tool vendor decision? - Radek: We have a clearly defined flow that doesn't address this situation. - Yes, tool can handle it. But we have a flow. - Bob: The flow question is a relevant question. - Arpad: Flow outlines the order things are executed and things pass in and out. - I don't think it is this BIRD's issue. - You could set up a simulation with AMI on one side and regular IBIS on the other without this BIRD. - Bob: It's relevant to whether we should force Executable_Tx and Executable_Rx. - It's within the AMI flow. - Michael M: Would resolving that be a block to approving this BIRD? - Arpad: That was my point. - It seems an open question with or without this BIRD. - We shouldn't force an I/O to have both if it doesn't have the functionality. - I don't see an issue with correcting that so both are not required. - Let's make sure this rule wouldn't be misinterpreted for the flow. - Radek: If we don't require both, it is still okay. - We are only using one flow direction at a time. - I think relaxing this requirement is okay. - Michael M: I have 3 changes to make to the draft. - Introduce the "_" characters. - Allow Executable_Tx or Executable_Rx or both. - 3-State models can't use Executable_Tx (only Executable). - Arpad: Motion to submit with those changes and recommend approval. - Mike L: Second. - Arpad: Anyone opposed? [none opposed] Enhanced C_comp modeling: - Arpad: Randy, would you like to discuss the C_comp proposal? - Randy: Would be nice if people could read it again and give me more feedback. - Arpad: Let's recap. - Randy: I think I'm at draft 6 [which is currently posted]. - Idea is to replace C_comp with improved modeling capability. - IBIS-ISS or touchstone files to describe the capacitance. - Ability to pass in some values to the model. - Single values or corner values. - Several types of models in terms of terminals. - C_comp hangs off A_signal terminal and connects to various voltage rails. - Another example allows an extra terminal to be brought out for an analog receive terminal. - Series filtering between die pad and input buffer - extra signal could be brought out. - C_comp in this case is series, perhaps a series resistance for example. - Also, two pseudo-differential buffers with a diff C_comp. - Pos and Neg signal terminals. - Arpad: You don't need the series aspect to do a differential approach, right? - Randy: Yes. - Arpad: Would another picture be good for that case? - Randy: Yes, I'd like to add that picture. - [back to reviewing draft] - Note about the fact that you have to provide the "N+1" reference terminal when using a touchstone file. - Required by the BIRD so it doesn't get referenced to node zero or something. - Arpad: Is it submitted? - Randy: No. - Bob: [referring to differential pair series C_comp picture] - This implies the receiver is true differential, which means [External Model]. - I think this figure is wrong. - We don't define I-V and K-T, we define I-V and v(t). - Randy: In the original discussions v(t) came up. - v(t) isn't used directly. - EDA tools have to figure out a way of de-embedding the C_comp model. - Originally did have the buffers labelled as v(t). - Bob: Do you use K-T in other pictures? I have concerns about that. - Arpad: Does the text mention K-T? - It doesn't, so in that regard we should just change the drawings. - Randy: We could use the figures as they are and add a statement regarding K-T. - Or we could remove K-T. - Arpad: I prefer to remove it. - Walter: [referring to differential picture again] - Bob is implying that this applies only to differential [External Model]? - Arpad: Bob is just objecting to this little true differential triangle shown. - Walter: I agree the picture is wrong. - Why can't this C_comp model work with legacy differentials? - Do we want to support a pseudo-differential, two single ended drivers and receivers? - Randy: What I meant to show was more of a pseudo-differential setup. - That's why the second buffer is shown as an inverted buffer associated through the diff_pin statement. - Sort of an implied buffer. Do we need a dashed line around it? - Arpad: That is not the issue. - I think Bob was commenting on the receiver symbol being only one triangle. - Randy: You can have that under receiver thresholds if you put in the differential receiver threshold keywords. - Bob: Thresholds, but, we can even do differential timing loads. - We added Rdiff and Cdiff. - For this figure, we would still apply this as two pseudo-differential buffers. - Arpad: If the triangle represents the I-V and clamp curve based receiver model, then I agree it has to be two triangles. - Bob: There are some syntactical changes relative to the interconnect proposal. - May need to update with that stuff. - Randy: Yes, it's a bit different. - I've started to incorporate those changes. - Do you think we need to finish the interconnect BIRD before finishing this? - Bob: Yes, or we will be out of sync. - No urgency for this BIRD since it's scheduled for the release after next. - Randy: Yes. - Arpad: How different is this from interconnect? - Interconnect allows the exact same thing except the new black box would not be part of the compensation algorithm. - Bob: C_comp model can work independent of the interconnect modeling proposal. - Arpad: Wouldn't it be easier to add this to the interconnect proposal? - If we have a box between the pad and the buffer terminal, and the only difference is whether the box is part of the compensation algorithm or not? - Bob: I see your point. - I'd prefer to keep them separate so the interconnect BIRD doesn't grow more. - Arpad: If we keep them separate, we should be careful to keep the same syntax. - Walter: You're absolutely right. - We could take this C_comp circuit and put it into the package model, and you could use the optional model name on the terminals, so it would be C_comp for a [Model]. - Inside the [Model] your C_comp keyword would be zero, and your v(t) curves then become the K(t) curves. - That's a relatively straight forward recommendation. - One could generate K(t) curves and then put the C_comp circuit in the package model. It is one way to do it. - Randy: That's an important point that you'd have K(t) not v(t) in the [Model]. - Arpad: If we're leaning toward waiting until the interconnect is finished, should we table this for the time being? - Randy: I'm okay with that. - Walter: Motion to table. - Bob: Second. - Arpad: Anyone opposed? [none opposed] - Arpad: I'm hoping next week to get motion on the back channel BIRD. - I have two entries for optimization and backchannel topics. - Walter: My proposal for optimization is a different approach. - I believe it is a superset of BIRD147.1. - The ball is in Cadence's court. - If they're okay with it, then BIRD147.1 gets tabled. - If they're not then we have to adjudicate which direction to take. - Arpad: I'd like to encourage everyone to take it seriously. - I'd like to make some progress next week. - Walter - It's been lingering. - No one out there was clamoring for it. - That is about to change shortly, so it is timely now. - Arpad: Thank you all for joining. ------------- Next meeting: 9 June 2015 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives